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Abstract 
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With current Network Mobility (NEMO) Basic Support, all 
communications to and from Mobile Network Nodes must go through the 
bi-directional tunnel established between the Mobile Router and Home 
Agent when the mobile network is away. This sub-optimal routing 
results in various inefficiencies associated with packet delivery, 
such as increased delay and bottleneck links leading to traffic 
congestion, which can ultimately disrupt all communications to and 
from the Mobile Network Nodes. Additionally, with nesting of Mobile 
Networks, these inefficiencies get compounded, and stalemate 
conditions may occur in specific dispositions. This document 
investigates such problems and provides the motivation behind Route 
Optimization (RO) for NEMO. 
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Introduction 


With current Network Mobility (NEMO) Basic Support [1], all 
communications to and from nodes in a mobile network must go through 
the bi-directional tunnel established between the Mobile Router and 
its Home Agent (also known as the MRHA tunnel) when the mobile 
network is away. Although such an arrangement allows Mobile Network 
Nodes to reach and be reached by any node on the Internet, 
limitations associated to the base protocol degrade overall 
performance of the network and, ultimately, can prevent all 
communications to and from the Mobile Network Nodes. 


Some of these concerns already exist with Mobile IPv6 [4] and were 
addressed by the mechanism known as Route Optimization, which is part 
of the base protocol. With Mobile IPv6, Route Optimization mostly 
improves the end-to-end path between the Mobile Node and 
Correspondent Node, with an additional benefit of reducing the load 
of the Home Network, thus its name. 


NEMO Basic Support presents a number of additional issues, making the 
problem more complex, so it was decided to address Route Optimization 
separately. In that case, the expected benefits are more dramatic, 
and a Route Optimization mechanism could enable connectivity that 
would be broken otherwise. In that sense, Route Optimization is even 
more important to NEMO Basic Support than it is to Mobile IPv6. 


This document explores limitations inherent in NEMO Basic Support, 
and their effects on communications between a Mobile Network Node and 
its corresponding peer. This is detailed in Section 2. It is 
expected that readers are familiar with general terminologies related 
to mobility in [4][2], NEMO-related terms defined in [3], and NEMO 
goals and requirements [5]. 


NEMO Route Optimization Problem Statement 


Given the NEMO Basic Support protocol, all data packets to and from 
Mobile Network Nodes must go through the Home Agent, even though a 
shorter path may exist between the Mobile Network Node and its 
Correspondent Node. In addition, with the nesting of Mobile Routers, 
these data packets must go through multiple Home Agents and several 
levels of encapsulation, which may be avoided. This results in 
various inefficiencies and problems with packet delivery, which can 
ultimately disrupt all communications to and from the Mobile Network 
Nodes. 


In the following sub-sections, we will describe the effects of a 
pinball route with NEMO Basic Support, how it may cause a bottleneck 
to be formed in the Home Network, and how these get amplified with 
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nesting of mobile networks. Closely related to nesting, we will also 
look into the sub-optimality even when Mobile IPv6 Route Optimization 
is used over NEMO Basic Support. This is followed by a description 
of security policy in the Home Network that may forbid transit 
traffic from Visiting Mobile Nodes in mobile networks. In addition, 
we will explore the impact of the MRHA tunnel on communications 
between two Mobile Network Nodes on different links of the same 
mobile network. We will also provide additional motivations for 
Route Optimization by considering the potential stalemate situation 
when a Home Agent is part of a mobile network. 


2.1. Sub-Optimality with NEMO Basic Support 


With NEMO Basic Support, all packets sent between a Mobile Network 
Node and its Correspondent Node are forwarded through the MRHA 
tunnel, resulting in a pinball route between the two nodes. This has 
the following sub-optimal effects: 


o Longer Route Leading to Increased Delay and Additional 
Infrastructure Load 


Because a packet must transit from a mobile network to the Home 
Agent then to the Correspondent Node, the transit time of the 
packet is usually longer than if the packet were to go straight 
from the mobile network to the Correspondent Node. When the 
Correspondent Node (or the mobile network) resides near the Home 
Agent, the increase in packet delay can be very small. However, 
when the mobile network and the Correspondent Node are relatively 
near to one another but far away from the Home Agent on the 
Internet, the increase in delay is very large. Applications such 
as real-time multimedia streaming may not be able to tolerate such 
increase in packet delay. In general, the increase in delay may 
also impact the performance of transport protocols such as TCP, 
since the sending rate of TCP is partly determined by the round- 
trip time (RIT) perceived by the communication peers. 


Moreover, by using a longer route, the total resource utilization 
for the traffic would be much higher than if the packets were to 
follow a direct path between the Mobile Network Node and 
Correspondent Node. This would result in additional load in the 
infrastructure. 


o Increased Packet Overhead 
The encapsulation of packets in the MRHA tunnel results in 


increased packet size due to the addition of an outer header. 
This reduces the bandwidth efficiency, as an IPv6 header can be 
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quite substantial relative to the payload for applications such as 
voice samples. For instance, given a voice application using an 8 
kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms 
(as in RFC 1889 [6]), the packet transmission rate will be 50 
packets per second. Each additional IPv6 header is an extra 320 
bits per packet (i.e., 16 kbps), which is twice the actual 
payload! 


Increased Processing Delay 


The encapsulation of packets in the MRHA tunnel also results in 
increased processing delay at the points of encapsulation and 
decapsulation. Such increased processing may include encryption/ 
decryption, topological correctness verifications, MTU 
computation, fragmentation, and reassembly. 


Increased Chances of Packet Fragmentation 


The augmentation in packet size due to packet encapsulation may 
increase the chances of the packet being fragmented along the MRHA 
tunnel. This can occur if there is no prior path MTU discovery 
conducted, or if the MTU discovery mechanism did not take into 
account the encapsulation of packets. Packet fragmentation will 
result in a further increase in packet delays and further 
reduction of bandwidth efficiency. 


Increased Susceptibility to Link Failure 


Under the assumption that each link has the same probability of 
link failure, a longer routing path would be more susceptible to 
link failure. Thus, packets routed through the MRHA tunnel may be 
subjected to a higher probability of being lost or delayed due to 
link failure, compared to packets that traverse directly between 
the Mobile Network Node and its Correspondent Node. 
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2.2. Bottleneck in the Home Network 


Apart from the increase in packet delay and infrastructure load, 
forwarding packets through the Home Agent may also lead to either the 
Home Agent or the Home Link becoming a bottleneck for the aggregated 
traffic from/to all the Mobile Network Nodes. A congestion at home 
would lead to additional packet delay, or even packet loss. In 
addition, Home Agent operations such as security check, packet 
interception, and tunneling might not be as optimized in the Home 
Agent software as plain packet forwarding. This could further limit 
the Home Agent capacity for data traffic. Furthermore, with all 
traffic having to pass through the Home Link, the Home Link becomes a 
single point of failure for the mobile network. 


Data packets that are delayed or discarded due to congestion at the 
Home Network would cause additional performance degradation to 
applications. Signaling packets, such as Binding Update messages, 
that are delayed or discarded due to congestion at the Home Network 
may affect the establishment or update of bi-directional tunnels, 
causing disruption of all traffic flow through these tunnels. 


A NEMO Route Optimization mechanism that allows the Mobile Network 
Nodes to communicate with their Correspondent Nodes via a path that 
is different from the MRHA tunneling and thereby avoiding the Home 
Agent may alleviate or even prevent the congestion at the Home Agent 
or Home Link. 


2.3. Amplified Sub-Optimality in Nested Mobile Networks 


By allowing other mobile nodes to join a mobile network, and in 
particular mobile routers, it is possible to form arbitrary levels of 
nesting of mobile networks. With such nesting, the use of NEMO Basic 
Support further amplifies the sub-optimality of routing. We call 
this the amplification effect of nesting, where the undesirable 
effects of a pinball route with NEMO Basic Support are amplified with 
each level of nesting of mobile networks. This is best illustrated 
by an example shown in Figure 1. 
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4+-------- +  +-------- +  +-------- + +-------- + 
| MR2_HA | | MR3_HA | | MR4_HA | | MRS_HA | 
+------ +-+ +---+----+ +---+----+ +-+------ + 
\ | | / 
4+-------- + 4------------------------------ + 
MR1_HA |---- | Internet | Seo CN1 
4+-------- + 4------------------------------ + 
ee 
root-MR | MRI | 
4+------- + 
| | 
4+------- + 4+------- + 
sub-MR | MR2 | | mR4 | 


Figure 1: An Example of a Nested Mobile Network 


Using NEMO Basic Support, the flow of packets between a Mobile 
Network Node, MNN, and a Correspondent Node, CN1, would need to go 
through three separate tunnels, illustrated in Figure 2 below. 


SS ea / /---------- 
EEE a / | | | 
MNN ----- (- -|- - -][- - -{|- - -| =- = (------ CN1 
MR3------- \ | | \------- MR3_HA 
MR2-------- X \ Ss tts MR2_HA 
MR1--------- MR1_HA 


Figure 2: Nesting of Bi-Directional Tunnels 
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This leads to the following problems: 
o Pinball Route 


Both inbound and outbound packets will flow via the Home Agents of 
all the Mobile Routers on their paths within the mobile network, 
with increased latency, less resilience, and more bandwidth usage. 
Appendix A illustrates in detail the packets’ routes under 
different nesting configurations of the Mobile Network Nodes. 


o Increased Packet Size 


An extra IPv6 header is added per level of nesting to all the 
packets. The header compression suggested in [7] cannot be 
applied because both the source and destination (the intermediate 
Mobile Router and its Home Agent) are different hop to hop. 


Nesting also amplifies the probability of congestion at the Home 
Networks of the upstream Mobile Routers. In addition, the Home Link 
of each upstream Mobile Router will also be a single point of failure 
for the nested Mobile Router. 


Sub-Optimality with Combined Mobile IPv6 Route Optimization 


When a Mobile IPv6 host joins a mobile network, it becomes a Visiting 
Mobile Node of the mobile network. Packets sent to and from the 
Visiting Mobile Node will have to be routed not only via the Home 
Agent of the Visiting Mobile Node, but also via the Home Agent of the 
Mobile Router in the mobile network. This suffers the same 
amplification effect of nested mobile network mentioned in 

Section 2.3. 


In addition, although Mobile IPv6 [4] allows a mobile host to perform 
Route Optimization with its Correspondent Node in order to avoid 
tunneling with its Home Agent, the "optimized" route is no longer 
optimized when the mobile host is attached to a mobile network. This 
is because the route between the mobile host and its Correspondent 
Node is subjected to the sub-optimality introduced by the MRHA 
tunnel. Interested readers may refer to Appendix A for examples of 
how the routes will appear with nesting of Mobile IPv6 hosts in 
mobile networks. 


The readers should also note that the same sub-optimality would apply 
when the mobile host is outside the mobile network and its 
Correspondent Node is in the mobile network. 
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Security Policy Prohibiting Traffic from Visiting Nodes 


NEMO Basic Support requires all traffic from visitors to be tunneled 
to the Mobile Router’s Home Agent. This might represent a breach in 
the security of the Home Network (some specific attacks against the 
Mobile Router’s binding by rogue visitors have been documented in 

[8] [9]). Administrators might thus fear that malicious packets will 
be routed into the Home Network via the bi-directional tunnel. Asa 
consequence, it can be expected that in many deployment scenarios, 
policies will be put in place to prevent unauthorized Visiting Mobile 
Nodes from attaching to the Mobile Router. 


However, there are deployment scenarios where allowing unauthorized 
Visiting Mobile Nodes is actually desirable. For instance, when 
Mobile Routers attach to other Mobile Routers and form a nested NEMO, 
they depend on each other to reach the Internet. When Mobile Routers 
have no prior knowledge of one another (no security association, 
Authentication, Authorization, and Accounting (AAA), Public-—Key 
Infrastructure (PKI), etc.), it could still be acceptable to forward 
packets, provided that the packets are not tunneled back to the Home 
Networks. 


A Route Optimization mechanism that allows traffic from Mobile 
Network Nodes to bypass the bi-directional tunnel between a Mobile 
Router and its Home Agent would be a necessary first step towards a 
Tit for Tat model, where MRs would benefit from a reciprocal 
altruism, based on anonymity and innocuousness, to extend the 
Internet infrastructure dynamically. 


Instability of Communications within a Nested Mobile Network 


Within a nested mobile network, two Mobile Network Nodes may 
communicate with each other. Let us consider the previous example 
illustrated in Figure 1 where MNN and CN2 are sharing a communication 
session. With NEMO Basic Support, a packet sent from MNN to CN2 will 
need to be forwarded to the Home Agent of each Mobile Router before 
reaching CN2, whereas, a packet following the direct path between 
them need not even leave the mobile network. Readers are referred to 
Appendix A.3 for detailed illustration of the resulting routing 
paths. 


Apart from the consequences of increased packet delay and packet 
size, which are discussed in previous sub-sections, there are two 
additional effects that are undesirable: 


o when the nested mobile network is disconnected from the Internet 
(e.g., MR1 loses its egress connectivity), MNN and CN2 can no 
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longer communicate with each other, even though the direct path 
from MNN to CN2 is unaffected; 


o the egress link(s) of the root Mobile Router (i.e., MR1) becomes a 
bottleneck for all the traffic that is coming in and out of the 
nested mobile network. 


A Route Optimization mechanism could allow traffic between two Mobile 
Network Nodes nested within the same mobile network to follow a 
direct path between them, without being routed out of the mobile 
network. This may also off-load the processing burden of the 
upstream Mobile Routers when the direct path between the two Mobile 
Network Nodes does not traverse these Mobile Routers. 


Stalemate with a Home Agent Nested in a Mobile Network 


Several configurations for the Home Network are described in [10]. 
In particular, there is a mobile home scenario where a (parent) 
Mobile Router is also a Home Agent for its mobile network. In other 
words, the mobile network is itself an aggregation of Mobile Network 
Prefixes assigned to (children) Mobile Routers. 


A stalemate situation exists in the case where the parent Mobile 
Router visits one of its children. The child Mobile Router cannot 
find its Home Agent in the Internet and thus cannot establish its 
MRHA tunnel and forward the visitor’s traffic. The traffic from the 
parent is thus blocked from reaching the Internet, and it will never 
bind to its own (grandparent) Home Agent. Appendix B gives a 
detailed illustration of how such a situation can occur. 


Then again, a Route Optimization mechanism that bypasses the nested 
tunnel might enable the parent traffic to reach the Internet and let 
it bind. At that point, the child Mobile Router would be able to 
reach its parent and bind in turn. Additional nested Route 
Optimization solutions might also enable the child to locate its Home 
Agent in the nested structure and bind regardless of whether or not 
the Internet is reachable. 


Conclusion 


With current NEMO Basic Support, all communications to and from 
Mobile Network Nodes must go through the MRHA tunnel when the mobile 
network is away. This results in various inefficiencies associated 
with packet delivery. This document investigates such inefficiencies 
and provides the motivation behind Route Optimization for NEMO. 
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We have described the sub-optimal effects of pinball routes with NEMO 
Basic Support, how they may cause a bottleneck to be formed in the 
Home Network, and how they get amplified with nesting of mobile 
networks. These effects will also be seen even when Mobile IPv6 
Route Optimization is used over NEMO Basic Support. In addition, 
other issues concerning the nesting of mobile networks that might 
provide additional motivation for a NEMO Route Optimization mechanism 
were also explored, such as the prohibition of forwarding traffic 
from a Visiting Mobile Node through an MRHA tunnel due to security 
concerns, the impact of the MRHA tunnel on communications between two 
Mobile Network Nodes on different links of the same mobile network, 
and the possibility of a stalemate situation when Home Agents are 
nested within a mobile network. 


Security Considerations 


This document highlights some limitations of NEMO Basic Support. In 
particular, some security concerns could prevent interesting 
applications of the protocol, as detailed in Section 2.5. 


Route Optimization for RFC 3963 [1] might introduce new threats, just 
as it might alleviate existing ones. This aspect will certainly be a 
key criterion in the evaluation of the proposed solutions. 
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Appendix A. Various Configurations Involving Nested Mobile Networks 


In the following sections, we try to describe different communication 
models that involve a nested mobile network and to clarify the issues 
for each case. We illustrate the path followed by packets if we 
assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms. 
Different cases are considered where a Correspondent Node is located 
in the fixed infrastructure, in a distinct nested mobile network as 
the Mobile Network Node, or in the same nested mobile network as the 
Mobile Network Node. Additionally, cases where Correspondent Nodes 
and Mobile Network Nodes are either standard IPv6 nodes or Mobile 
IPv6 nodes are considered. As defined in [3], standard IPv6 nodes 
are nodes with no mobility functions whatsoever, i.e., they are not 
Mobile IPv6é or NEMO enabled. This means that they cannot move around 
keeping open connections and that they cannot process Binding Updates 
sent by peers. 


.1. CN Located in the Fixed Infrastructure 
The most typical configuration is the case where a Mobile Network 


Node communicates with a Correspondent Node attached in the fixed 
infrastructure. Figure 3 below shows an example of such topology. 


4+-------- + +-------- + +-------- + 
| MRI_HA | | MR2_HA | | MR3_HA | 
+---+----+ +---+----+ +---+----+ 

| | | 
4------------------------- + 
| Internet |----+ CN 
4------------------------- + 
| | 
4+---+---+ 4+--+----- + 
root-MR | MRI | | VMN_HA 
4+---+---+ 4+-------- + 


4+---+---+ 
sub-MR | MR2 | 
4+---+---+ 
PA A 
sub-MR | MR3 | 
4+---+---+ 


a 


MNN 


Figure 3: CN Located at the Infrastructure 
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A.1.1. Case A: LFN and Standard IPv6 CN 


The simplest case is where both MNN and CN are fixed nodes with no 
mobility functions. That is, MNN is a Local Fixed Node, and CN is a 
standard IPv6 node. Packets are encapsulated between each Mobile 
Router and its respective Home Agent (HA). As shown in Figure 4, in 
such a case, the path between the two nodes would go through: 


1 2 3 4 3 2 1 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 
LFN IPv6 Node 


The digits represent the number of IPv6 headers. 


Figure 4: MNN and CN Are Standard IPv6é Nodes 
A.1.2. Case B: VMN and MIPv6 CN 


In this second case, both end nodes are Mobile IPv6-enabled mobile 
nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 Route 
Optimization may thus be initiated between the two and packets would 
not go through the Home Agent of the Visiting Mobile Node or the Home 
Agent of the Correspondent Node (not shown in the figure). However, 
packets will still be tunneled between each Mobile Router and its 
respective Home Agent, in both directions. As shown in Figure 5, the 
path between MNN and CN would go through: 


1 2 3 4 3 2 1 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 
VMN MIPv6 


Figure 5: MNN and CN Are MIPv6 Mobile Nodes 
A.1.3. Case C: VMN and Standard IPv6 CN 


When the communication involves a Mobile IPv6 node either as a 
Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route 
Optimization cannot be performed because the standard IPv6 
Correspondent Node cannot process Mobile IPv6 signaling. Therefore, 
MNN would establish a bi-directional tunnel with its HA, which causes 
the flow to go out the nested NEMO. Packets between MNN and CN would 
thus go through MNN’s own Home Agent (VMN_HA). The path would 
therefore be as shown in Figure 6: 
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2 3 4 5 4 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA 
VMN 
3 
1 2 | 
CN --- VMN_HA --- MR3_HA 
IPv6 Node 


Figure 6: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node 


Providing Route Optimization involving a Mobile IPv6 node may require 
optimization among the Mobile Routers and the Mobile IPv6 node. 


A.2. CN Located in Distinct Nested NEMOs 


The Correspondent Node may be located in another nested mobile 
network, different from the one MNN is attached to, as shown in 


Figure 7. We define such configuration as "distinct nested mobile 
networks". 
4+-------- +  +-------- +  +-------- +  +-------- + 
| MR2_HA | | MR3_HA | | MR4_HA | | MRS_HA | 
4+------ +-+ +---+----+ +---+----+ +-+------ + 
\ | | / 
4+-------- + 4------------------------- + 4+-------- + 
MR1_HA |----| Internet |----| VMN_HA 
4+-------- + 4+------------------------- + 4+-------- + 
| | 
4+---+---+ 4+---+---+ 
root-MR | MRI | | MR4 | 
+---+---+ +---+---+ 
| | 
4+---+---+ 4+---+---+ 
sub-MR | MR2 | | MR5 | 
+---+---+ +---+---+ 
| | 
+---+---+ ----+---- 
sub-MR | MR3 | CN 
4+---+---+ 
| 
a 
MNN 


Figure 7: MNN and CN Located in Distinct Nested NEMOs 
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A.2.1. Case D: LFN and Standard IPv6 CN 


Similar to Case A, we start off with the case where both end nodes do 
not have any mobility functions. Packets are encapsulated at every 
Mobile Router on the way out of the nested mobile network, 
decapsulated by the Home Agents, and then encapsulated again on their 
way down the nested mobile network. 


1 2 3 4 3 2 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2 HA --- MR3_HA 
LFN | 
| 1 
1 2 3 2 | 
CN --- MR5 --- MR4 --- MR4_ HA --- MR5_HA 
IPv6 Node 


Figure 8: MNN and CN Are Standard IPv6é Nodes 


A.2.2. Case E: VMN and MIPv6 CN 


Similar to Case B, when both end nodes are Mobile IPv6 nodes, the two 
nodes may initiate Mobile IPv6 Route Optimization. Again, packets 
will not go through the Home Agent of the MNN or the Home Agent of 
the Mobile IPv6 Correspondent Node (not shown in the figure). 
However, packets will still be tunneled for each Mobile Router to its 
Home Agent and vice versa. Therefore, the path between MNN and CN 


would go through: 


1 2 3 4 3 2 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 
VMN 
1 
1 2 3 2 | 
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 
MIPv6 Node 


Figure 9: MNN and CN Are MIPv6 Mobile Nodes 


A.2.3. Case F: VMN and Standard IPv6 CN 


Similar to Case C, when the communication involves a Mobile IPv6 node 
either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 
Route Optimization cannot be performed because the standard IPv6 
Correspondent Node cannot process Mobile IPv6 signaling. MNN would 
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therefore establish a bi-directional tunnel with its Home Agent. 
Packets between MNN and CN would thus go through MNN’s own Home Agent 
as shown in Figure 10: 


2 3 4 5 4 3 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 
VMN 
2 
1 2 3 2 1 
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA 
IPv6 Node 


Figure 10: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node 
A.3. MNN and CN Located in the Same Nested NEMO 


Figure 11 below shows the case where the two communicating nodes are 
connected behind different Mobile Routers that are connected in the 
same nested mobile network, and thus behind the same root Mobile 
Router. Route Optimization can avoid packets being tunneled outside 
the nested mobile network. 


4+-------- +  +-------- +  +-------- +  +-------- + 
| MR2_HA | | MR3_HA | | MR4_HA | | MRS_HA | 
4+------ +-+ +---+----+ +---+----+ +-+------ + 
\ | | / 
4+-------- + 4------------------------- + 4+-------- + 
MR1_HA |----| Internet |----| VMN_HA 
4+-------- + 4------------------------- + 4+-------- + 
eens 
root-MR | MRI | 
4+------- + 
| | 
4+------- + 4+------- + 
sub-MR | MR2 | | MR4 | 
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Figure 11: MNN and CN Located in the Same Nested NEMO 
A.3.1. Case G: LFN and Standard IPv6 CN 


Again, we start off with the case where both end nodes do not have 
any mobility functions. Packets are encapsulated at every Mobile 
Router on the way out of the nested mobile network via the root 
Mobile Router, decapsulated and encapsulated by the Home Agents, and 
then make their way back to the nested mobile network through the 
same root Mobile Router. Therefore, the path between MNN and CN 
would go through: 


1 2 3 4 3 2 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 
LFN 
1 
1 2 3 4 3 2 
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 
IPv6 Node 


Figure 12: MNN and CN Are Standard IPv6 nodes 
A.3.2. Case H: VMN and MIPv6 CN 


Similar to Case B and Case E, when both end nodes are Mobile IPv6 
nodes, the two nodes may initiate Mobile IPv6 Route Optimization, 
which will avoid the packets going through the Home Agent of MNN or 
the Home Agent of the Mobile IPv6 CN (not shown in the figure). 
However, packets will still be tunneled between each Mobile Router 
and its respective Home Agent in both directions. Therefore, the 
path would be the same as with Case G and go through: 


1 2 3 4 3 2 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 
LFN | 
|1 
1 2 3 4 3 2 
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 


MIPv6 Node 


Figure 13: MNN and CN Are MIPv6 Mobile Nodes 


Ng, et al. Informational [Page 18] 


RFC 4888 NEMO RO Problem Statement July 2007 


A.3.3. Case I: VMN and Standard IPv6 CN 


As for Case C and Case F, when the communication involves a Mobile 
IPv6 node either as a Visiting Mobile Node or as a Correspondent 
Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, 
MNN will establish a bi-directional tunnel with its Home Agent. 
Packets between MNN and CN would thus go through MNN’s own Home 


Agent. The path would therefore be as shown in Figure 14: 
2 3 4 9 4 3 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 
VMN | 
|2 
VMN_HA 
[ei 
1 2 3 4 3 2 | 
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 
IPv6 Node 


Figure 14: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node 
A.4. CN Located Behind the Same Nested MR 
Figure 15 below shows the case where the two communicating nodes are 


connected behind the same nested Mobile Router. The optimization is 
required when the communication involves MIPv6-enabled nodes. 
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4+-------- + +-------- + $-------- + $-------- + 
| MR2_HA | | MR3_HA | | MR4_HA | | MRS_HA | 
4+------ +-+ +---+----+ +---+----+ +-+------ + 
\ | | / 
4+-------- + 4------------------------- + 4+-------- + 
MR1_HA |----| Internet |----| VMN_HA 
4+-------- + 4------------------------- + 4+-------- + 
PE 
root-MR | MRI | 
4+---+---+ 
| 
4+------- + 
sub-MR | MR2 | 
4+---+---+ 
ee ae 
sub-MR | MR3 | 
4+---+---+ 
ae nee 
MNN CN 


Figure 15: MNN and CN Located Behind the Same Nested MR 
A.4.1. Case J: LFN and Standard IPv6 CN 


If both end nodes are Local Fixed Nodes, no special function is 
necessary for optimization of their communications. The path between 
the two nodes would go through: 


1 
MNN --- CN 
LFN IPv6 Node 


Figure 16: MNN and CN Are Standard IPv6 Nodes 


A.4.2. Case K: VMN and MIPv6 CN 


Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two 
nodes may initiate Mobile IPv6 Route Optimization. Although few 
packets would go out the nested mobile network for the Return 
Routability initialization, however, unlike Case B and Case E, 
packets will not get tunneled outside the nested mobile network. 
Therefore, packets between MNN and CN would eventually go through: 
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1 
MNN --- CN 
VMN MIPv6é Node 


Figure 17: MNN and CN are MIPv6 Mobile Nodes 


If the root Mobile Router is disconnected while the nodes exchange 
keys for the Return Routability procedure, they may not communicate 
even though they are connected on the same link. 


A.4.3. Case L: VMN and Standard IPv6 CN 


When the communication involves a Mobile IPv6 node either as a 
Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 
Route Optimization cannot be performed. Therefore, even though the 
two nodes are on the same link, MNN will establish a bi-directional 
tunnel with its Home Agent, which causes the flow to go out the 
nested mobile network. The path between MNN and CN would require 
another Home Agent (VMN_HA) to go through for this Mobile IPv6 node: 


2 3 4 5 4 3 
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 
VMN | 
| 2 
VMN_HA 
| 1 
1 2 3 4 3 2 | 
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 
IPv6 Node 


Figure 18: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node 


However, MNN may also decide to use its Care-of Address (CoA) as the 
source address of the packets, thus avoiding the tunneling with the 
MNN’s Home Agent. This is particularly useful for a short-term 
communications that may easily be retried if it fails. Default 
Address Selection [11] provides some mechanisms for controlling the 
choice of the source address. 
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Appendix B. Example of How a Stalemate Situation Can Occur 


Section 2.7 describes the occurrence of a stalemate situation where a 
Home Agent of a Mobile Router is nested behind the Mobile Router. 
Here, we illustrate a simple example where such a situation can 
occur. 


Consider a mobility configuration depicted in Figure 19 below. MR1 

is served by HA1/BR and MR2 is served by HA2. The ’BR’ designation 

indicates that HA1 is a border router. Both MR1 and MR2 are at home 
in the initial step. HA2 is placed inside the first mobile network, 
thus representing a "mobile" Home Agent. 


V a CN 
renegan enS + 
home link 1 paer ee 
Se NG pe ye ee | HA1/BR |--- Internet 
| PaHSaTess + | 
| AATE A + 
+--+--+ +----- + 
| MR1 | | H22 | 


—+-------- +-- mobile net 1 / home link 2 


4+--+--+ +--+--+ 
| MR2 | | LEN | 
+--+--+  +--+--+ 


-—+-------- +- mobile net 2 
Figure 19: Initial Deployment 
In Figure 19 above, communications between CN and LFN follow a direct 
path as long as both MR1 and MR2 are positioned at home. No 
encapsulation intervenes. 
In the next step, consider that the MR2’s mobile network leaves home 


and visits a foreign network, under Access Router (AR) like in 
Figure 20 below. 
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Ng, 


CN 
4+---------- + 
home link 1 +-------- + 
soto s 557 | HA1/BR |---| Internet 
| +-------- + | | 
+--t--+ +----- + 4+---------- + 
| MR1 | | H22 | \ 
+--t--+ +--+--+ 4+----- + 
| | | AR | 
ShoSs sess +- mobile net 1 E 
home link 2 | 
+--+--+ +----- + 
| MR2 | | LFN | 


mobile net 2 -+-------- J= 
Figure 20: Mobile Network 2 Leaves Home 


Once MR2 acquires a Care-of Address under AR, the tunnel setup 
procedure occurs between MR2 and HA2. MR2 sends a Binding Update to 
HA2 and HA2 replies with a Binding Acknowledgement to MR2. The bi- 
directional tunnel has MR2 and HA2 as tunnel endpoints. After the 
tunnel MR2HA2 has been set up, the path taken by a packet from CN 
towards LFN can be summarized as: 


CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LEN. 


Non-encapsulated packets are marked "->" while encapsulated packets 
are marked "=>", 


Consider next the attachment of the first mobile network under the 
second mobile network, like in Figure 21 below. 


After this movement, MR1 acquires a Care-of Address valid in the 
second mobile network. Subsequently, it sends a Binding Update (BU) 
message addressed to HA1. This Binding Update is encapsulated by MR2 
and sent towards HA2, which is expected to be placed in mobile net 1 
and expected to be at home. Once HA1/BR receives this encapsulated 
BU, it tries to deliver to MR1. Since MR1 is not at home, anda 
tunnel has not yet been set up between MR1 and HA1, HA1 is not able 
to route this packet and drops it. Thus, the tunnel establishment 
procedure between MR1 and HA1 is not possible, because the tunnel 
between MR2 and HA2 had been previously torn down (when the mobile 
net 1 moved from home). The communications between CN and LFN stops, 
even though both mobile networks are connected to the Internet. 
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[== CN 
4+---------- + 
4+-------- + 
| HA1/BR |---| Internet 
+-------- + | | 
4+---------- + 
\ 
+----- + 
| AR | 
+--+--+ 
| 
+--+--+ 
| MR2 | 
+--+--+ 


If both tunnels 
simultaneously, 
tunnels MR1-HA1 
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mobile net 2 -+---- 


+--+--4+ 
| MR1 | 
+--+--+ 


mobile net 1 -+---- 


4+----- + 
| LEN | 
+--+--+ 
| 
----+-— 
4+----- + 
| HA2 | 
+--+--+ 
| 
—----+-— 


July 2007 


Figure 21: Stalemate Situation Occurs 


between MR1 and HA1, and between MR2 and HA2, were up 


they would have "crossed over" 
and MR2-HA2 were drawn in Figure 21, 


each other. If the 


it could be 


noticed that the path of the tunnel MR1-HA1 includes only one 
tunnel MR2-HA2 (the MR2 endpoint). 
are crossing over each other if the IP path between two endpoints of 
one tunnel includes one and only one endpoint of the other tunnel 


endpoint of the 


(assuming that both tunnels are up). 
tunnel are included in the path of the other tunnel, 


simply encapsulating each other. 
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